In the last few years, the number of Internet users and the information offered has increased exponentially, together with the number of critical business and private activities relying on the network availability and the reliability of the connection. Even more people are used to access Internet frequently to make transactions (e.g. to buy goods and services, to book flights, to make banking transactions or trading), to access remote information (e.g. to read e-mails, to download files), to communicate (e.g. to chat, to make audio-video communications). That number is bound to continue to increase in the near future, since the growing range of IP (Internet Protocol)-capable mobile devices (e.g. PDAs (Personal Digital Assistant), smart-phones and laptops) and the growing availability of broadband wireless infrastructure (e.g. Wi-Fi [Wireless Fidelity for 802.11 network], GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), EDGE (Enhanced Data-Rates for GSM Evolution), 1XRTT (Radio Transmission Technology), CDMA2000 (Code Division Multiple Access), Bluetooth, etc.) are beginning to change our concept of Internet access from “static” or “nomadic” to “mobile”: nowadays the possibility of connecting to the Internet is no longer limited to a few network access points (e.g. at home, office, school or university) since it is possible to have network availability wherever the user is.
Ubiquitous access availability is important but the underlying concept is to provide reliable and continuous Internet access during the mobility of people nowadays, i.e. a seamless handover between different network access technologies. This is important since not all network technologies are suited to cover similar need as range, access speed, etc. Therefore, network technologies as e.g. GPRS based on GSM (Global System for Mobile Communications), UMTS, WLAN (Wireless Local Area Network) or Bluetooth differ greatly in their characteristics and availability. However, co-existence of different network access technologies under the Internet Protocol (IP) brings problems when the user switches between access technologies and/or access providers: since IP addresses are assigned to a fixed location in the network, when we refer to mobile devices a new IP network address must be assigned with each change of network location (access technology and/or provider). This makes impossible a transparent, mobile access, leading to the IP applications to be restarted (therefore losing the current session), data packets to be lost and transmission rate to be slowed down.
Think about a busy manager who is working with his laptop in his office, connected via Ethernet or Wi-Fi to the company network. Suppose that he has a meeting in another city and he must leave the office to reach the local airport by taxi. Suppose he is using a Client/Server application requiring an always-on connection to complete a business-critical transaction. This manager has a problem. When he leaves the office to catch the taxi, the Wi-Fi/Ethernet connection will be lost and the application and the session that he is using will crash with possible loss of sensitive information. In order to complete his work, he will have to establish a GPRS/EDGE/UMTS/etc connection and to reload the Client application, repeating all the necessary authentication steps. At this point, he is able to continue his work, but only with the limited bandwidth offered by GPRS, EDGE or UMTS. When he reaches the airport, where a public hot spot is available, he could work with the larger and cheaper bandwidth of Wi-Fi; but in order to use the Wi-Fi technology, he has to switch from his current network connection to the Wi-Fi connection. This obviously involves all the above-mentioned problems, including the application crash and the new authentication. It is clear that a system should be capable of managing an automatic and transparent handover between different network access technologies and/or access providers without interrupting active network applications or sessions. This need is well known in the IT (Information Technologies) and Telecommunication worlds, which is also shown in the prior art by several patent publications e.g. by Nokia Mobile Phones LTD (EP 0 998 094 A2), Nortel Networks Limited (EP 1 089 495 A2), Swisscom Mobile AG (WO 02/103978 A2), KONINKLIJKE PHILIPS ELECTRONICS N.V. (WO 03/065682 A1 and WO 03/065654 A1), Columbitech AB (WO 02/43348 A1), and documents e.g. “Supporting CORBA Applications in a Mobile Environment” MOBICOM '99 by HAAHR M et al., “IP mobility support”—IETF RFC 2002—1996 by C. Perkins. Another important need is that such a system should be completely flexible in order to be easily and quickly adapted to the variation of wireless network standards (e.g. in the Wi-Fi environment, the introduction of IEEE 802.11g or IEEE 802.11i (IEEE: Institute of Electrical and Electronics Engineers)), in order to be easily and quickly adapted to new network access technologies (e.g. based on the LEO [Low Earth Orbit] satellites), in order to be easily adapted to different OS (Operating System) (Windows, Linux, Symbian, PalmOS etc.) and to the future releases of such OS, and in order to be easily adapted to various mobile devices with different memories, computational capability and so on. Currently there are no standards providing a roaming service between the various kinds of wired/wireless networks. This lack of standards makes wired/wireless roaming a big issue if this problem is tackled at the lowest levels of the OSI-7 Layers Protocol Stack (Open System Interconnection). The prior art mentioned above satisfies the need and manages the seamless handover proposing a mechanism that modifies one of the layers of the OSI protocol stack (Data Link Layer, Network Layer or Session Layer) or that introduces one or more sub-layers (see FIGS. 35 and 36). But a modification of the OSI protocol stack requires a lot of low-level work that is platform dependent, i.e. that must be done every time a new OS has to be supported, and this has a negative impact on the flexibility and portability of the solution. Furthermore, if one or more sub-layers are introduced, one or more encapsulations have also to be introduced and this increments the amount of data to be exchanged and the likelihood of the IP packet fragmentation.
Virtually all networks in use today are based in some fashion on the Open Systems Interconnection (OSI) reference model of the ISO (International Organization for Standardization) standards. The core of this standard is the OSI Reference Model, a set of seven layers that define the different stages that data must go through to travel from one device to another over a network. Referring to FIG. 1, an overall scheme for the standard OSI-7 Layers Protocol Stack is shown. The OSI standard is the only internationally accepted framework of standards for communication between different systems made by different vendors. The OSI layers are: Physical Layer (L1), which corresponds to the physical network interface, deals with the physical means of transmitting data over communication lines (referring in a network environment to various Network Interface Cards). On L1 each node of a network, for example, with a packet-switched interface has an unambiguous network address, these network addresses being called a Data Link Control (DLC) address or a Media Access Control (MAC) address. In the case of networks which conform to the IEEE 802 standard (such as Ethernet, for example), the DLC addresses are usually called MAC addresses. To be called a DLC address, an address must fulfill at least the OSI reference model. In other words, a DLC address, or respectively a MAC address, is a hardware address that identifies the node or respectively the physical network interface unambiguously in the network. Some protocols, such as Ethernet or Token Ring, for example, use the DLC/MAC address exclusively, i.e. they cannot communicate with the respective node without this address. A circuit-switched interface, on the other hand, has no such DLC or MAC address, i.e. thus also no corresponding identification DLCI (DLC Identifier). Examples of protocols using circuit-switched interfaces are inter alia PPP (Point to Point Protocol), SLIP (Serial Line Internet Protocol) or GPRS (Generalized Packet Radio Service). Basic data units of L1 are “Bits”. Data link Layer (L2), which is concerned with procedures and protocols for operating the communication lines. Basic data units of L2 are “Frames”. Network Layer (L3), which provides switching and routing technologies, creating logical paths for transmitting data from node to node. This information may include network or Internet protocol addresses for communication nodes. L3does not ensure reliability and its basic data units are “Packets”. Transport Layer (L4), which defines the rules for information exchange, e.g. information about various network protocols. L4 ensures that the data is transmitted reliably between the communicating systems, it disassembles and re-assembles data into smaller units for the Network layer. Basic data units of L4 are “Segments”. Session Layer (L5), which negotiates communication settings, establishes, maintains and ends communications between the two communicating systems. It synchronizes operations and coordinates rules for communicating. Presentation Layer (L6), which takes the data provided by L7 and converts it into a standard format that the other layers can understand. Basic data units are of L6 are “Messages”. Application Layer (L7), which supports application and end-user processes. This is the layer that actually interacts with the operating system or applications whenever the user chooses to transfer files, read messages or perform other network-related activities. Within the OSI Reference Model, the protocols are what describe the rules that control horizontal communication, that is, conversations between processes that run at corresponding layers. At every layer (except layer one) these communications ultimately take the form of some sort of message that is sent between corresponding software elements on two or more devices. Since these messages are the mechanism for communicating information between protocols, they are most generally called protocol data units (PDUs). Each PDU has a specific format that implements the features and requirements of the protocol. The communication between layers higher than layer one is logical; the only hardware connection is at the physical layer. Thus, in order for a protocol to communicate, it must pass down its PDU to the next lower layer for transmission. In the OSI terminology, lower layers are said to provide services to the layers immediately above them. One of the services that each layer provides is this function: to handle and to manage the data received from the layer above. At any particular layer N, a PDU is a complete message that implements the protocol at that layer. However, when this “layer N PDU” is passed down to layer N−1, it becomes the data that the layer N−1 protocol has to service. Thus, the layer N protocol data unit (PDU) is called the layer N−1 service data unit (SDU). The job of layer N−1 is to transport this SDU, which it does in turn by placing the layer N SDU into its own PDU format, preceding the SDU with its own headers and appending footers as necessary. This process is called data encapsulation, because the entire contents of the higher-layer message are encapsulated as the data payload of the message at the lower layer. What does layer N−1 do with its PDU? It passes it down to the next lower layer, where it is treated as a layer N−2 SDU. Layer N−2 creates a layer N−2 PDU containing the layer N−1 SDU and layer N−2's headers and footers. And so the process continues, all the way down to the physical layer. In the theoretical model, what you end up with is a message at layer 1 that consists of application-layer data that is encapsulated with headers and/or footers from each of layers 7 through 2 in turn.
As mentioned, in the prior art we can find the following six patent applications, which can be regarded as representing the prior art for the issue of avoiding the client application shutdown during the wireless network connection switches. These are WO 02/103978 A2 (Swisscom Mobile AG), EP 1 089 495 A2 (Nortel Networks Limited), EP 0 998 094 A2 (Nokia Mobile Phones LTD), WO 03/065682 A1 and WO 03/065654 A1 (KONINKLIJKE PHILIPS ELECTRONICS N.V.) and WO 02/43348 A1 (Columbitech AB). All these patent applications, except WO 02/43348 A1, make use of the concept of Mobile IP as described in IP Mobility Support—IETF RFC 2002 (C. Perkins—IBM IP Mobility Support—IETF RFC 2002—October 1996). Internet makes use of the IP (Internet Protocol) to route data packets (datagrams) from the source to the destination. The source and the destination must have an IP address unique in Internet in order to be reached, something like the telephone number in the telephony world. When the destination address of the data packets is a mobile node this means that a new IP network address must be assigned with each change of network location, which makes transparent mobile accesses impossible. These mobility problems were solved by the Mobile IP standard of the IETF. Mobile IP allows the mobile node to use two IP addresses. One of these addresses is the normal, static IP address (home address), which indicates the location of the home network, whereas the second is a dynamic IP care-of address, which provides information about its current point of attachment to the Internet. The assignment of the two addresses allows the IP data packets to be rerouted to the correct, momentary address of the mobile node. The Mobile IP provides for registering the care-of address with a Home Agent. The Home Agent is normally a fixed network node, which administers the two addresses of the mobile node (home address and care-of address) and reroutes or routes the corresponding data packets: it sends datagrams destined for the mobile node through an IP tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
Unfortunately, the Mobile IP of the IETF does not solve all the mobility problems: if, for instance, a user would like to switch between two different network interfaces while an IP application is running, the IP connection is interrupted at the moment when he leaves the old network link. This connection is interrupted at least until the new location, i.e. the new care-of address, is known and it has been registered at the so-called Home Agent. If the interruption time for the change exceeds the time-out delays specified e.g. in the TCP (Transfer Control Protocol), the IP connection is of course interrupted anyway. Even when the interruption time lies within the time-out delays specified e.g. in the TCP, however, the IP applications are not able to maintain the connection if a physical network interface is not permanently available. Thereby IP applications normally have to be restarted after a network connection switch in order to access a new IP data tunnel. WO 02/103978 A2 provides a method and a system to avoid the interruption of service in case of network connection switch with a mechanism operating at layer 3 (Network layer) of the OSI-7 Layers Protocol Stack. In FIG. 2 the reference numeral 10 refers to the mobile device, 11 is the application layer of the IP applications and 12 refers to the TCP layer. The solution of WO 02/103978 A2 is based on the three main layers or respectively main modules 131 to 134 which are designated jointly as mobile module by the reference numeral 13. The first layer consists of a mobile IP module 131 and/or an IPSec module 132. The second layer is the virtual network interface 133 of the solution and the third layer is an interface administration module 134 to handle the physical network interfaces 14-17. Finally, reference numerals 21 to 24 accordingly stand for the various heterogeneous networks and 30 designates the usual, worldwide IP backbone network. The Virtual IP Network Interface (133 in FIG. 2) and the Interface Administration Module (134 in FIG. 2) make transparent to the Client applications (11-12 in FIG. 2) the care-of IP address changing. The main drawback of WO 02/103978 A2 is that, operating at layer 3, the implementation requires a great deal of low-level work for each supported operating system. This vast amount of work reduces the flexibility of this solution in case of variation in wireless networks standards or in case of introduction of new wireless networks. WO 02/103978 A2 is based on the concepts of Mobile IP, and it solves its problem of IP applications restart in case of a network connection switch. Consequently all the coordination issues between the mobile node and the home agent have to be considered and implemented by this patent. Furthermore WO 02/103978 A2 requires that the Virtual IP Network Interface be under a custom Mobile IP and/or IPSec module (131-132 in FIG. 2) that provides Mobile IP and security features (authenticity of the interlocutors, confidentiality of the data exchanged and hashing systems to check whether the data exchanged have been modified during the transport by an unauthorized third party). Using a custom IPSec module all the above-mentioned security features have to be implemented, thus the widespread security commercial products operating at transport (L4) or network (L3) or lower level (L2, L1) can't be used. This patent does not take care of how the network connection is made and, operating at layer 3, an automatic or semi-automatic/assisted way to make the connection is difficult to be achieved. The solution of WO 02/103978 A2 is limited in its architectural features by Mobile IP concepts, on which it's based.
The mentioned document EP 1 089 495 A2 of Nortel shows a method and a system to make a change of the physical interfaces without the active IP applications being interrupted or having to be restarted because their link to the original interface has been lost (see FIG. 3). As FIG. 3 shows, the solution is based on a typical OSI-7 Layer Protocol Stack where reference numeral 16 designates the Network Layer (L3). Reference numeral 60 stands for an NAA (Network Access Arbitrator), 62 are the network adapters (NICs), 64 are the adapter drivers and 36 is a specific computer hardware platform. Nortel proposes an NAA (Network Access Arbitrator) 60 to reroute, via a single fixed MAC (Media Access Control) address of the so-called primary NIC (Network Interface Card) 62, the various MAC addresses of the individual configurable physical network interfaces available. The NAA 60 connects the layer 2 (Data Link layer) of the available NICs 62, and it reroutes the data packets from the primary NIC 62 to the corresponding MAC address of a further network interface (secondary NIC) 62. The NAA 60 provides a virtual adapter driver, and it requires that at least one physical interface with a MAC address must be permanently available. The major drawback of the Nortel invention is that it is sensitive to the definition of the network interface hardware-related address. If the address does not correspond to the IEEE 802 standard (MAC addresses) and if the new address standard has not been explicitly defined beforehand in the NM, the NM does not function with these interfaces since it can no longer reroute the MAC addresses. Another disadvantage arises from the explicit use of the MAC addresses: circuit-switched interfaces (GPRS, PPP (Point-to-Point Protocol), SLIP (Serial Line Internet Protocol)) do not have any corresponding MAC or network addresses. Since the NM is able to register only devices with MAC addresses in order to reroute the data packets, circuit-switched interfaces are not available to the NAA even though their connection to the IP layer should also be possible. A further disadvantage of EP 1 089 495 A2 has its origin in being based on the concepts of Mobile IP. In fact, EP 1 089 495 A2 solves the problem of IP applications restart in case of network connection switch, but consequently, all the coordination issues between the mobile node and the home agent have to be considered and implemented by this solution. Additionally, this solution does not take care of how the network connection is made which can be problematic for many applications. Like the solution of WO 02/103978 A2, the solution of EP 1 089 495 A2 is limited in its architectural features by Mobile IP concepts, on which it's based.
The mentioned document EP0 998 094 A2 of Nokia provides another method and system to avoid the interruption of service in case of network connection switch. The mechanism of the solution operates between layer 2 (Data link layer) and layer 3 (Network layer) (see FIG. 4). In FIG. 4 is PD designates a Protocol Driver, NT refers to the Windows NT standards of Microsoft and NISD is a Network Interface Selection Driver. The main drawback of this solution is that, operating between layer 2 and 3, the implementation requires a great deal of low-level work for each supported operating system. This vast amount of work reduces the flexibility of this solution in case of variation in wireless networks standards or in case of introduction of new wireless networks. Again, EP0 998 094 A2 is based on the concepts of Mobile IP to solve the problem of IP applications restart in case of network connection switch. Consequently all the coordination issues between the mobile node and the home agent have to be considered and implemented by this solution. Like the solution of WO 02/103978 A2 and EP 1 089 495 A2, additionally, the solution of EP 0 998 094 A2 is limited in its architectural features by Mobile IP concepts, on which it's based.
The mentioned document WO 03/065682 A1 provides the seamless handover working at the lowest three OSI layers (Physical, Data Link and Network). The routing, including detection of available networks, address configuration and handover is performed by a Routing Manager object (RM). The Routing Manager object communicates with the bearer objects handling the wireless network interfaces. WO 03/065682 A1 makes use of an IP-IP tunnel to provide the routing mechanism, so it makes use of the packet encapsulation. Like Mobile IP (RFC2002), it makes use of an IP address (called IP_CLIENT, the home address in the Mobile IP terminology) that remains the same during a handover from a first communications standard to a second communications standard (the changing mobile device IP address assigned by the wireless connectivity bearer is called IP_BEARER, the care-of address in the Mobile IP terminology). Finally, it has to grant the security of the communication: the mobile devices have to be identified and authorized in order to communicate with the servers. The main drawback of this solution is that, operating at layers 2 and 3, the implementation requires a great deal of low-level work for each supported operating system. This vast amount of work reduces the flexibility of this solution in case of variation in wireless networks standards or in case of introduction of new wireless networks. Like the other solutions mentioned, this solution is limited in its architectural features by Mobile IP concepts, from which it has been derived.
The mentioned document WO 03/065654 A1 is very similar to the WO 03/065682 A1 and share with it the above described features and drawbacks. It also introduces the possibility that an application, modifying its source code, could access, in a cross-layering way, some low level information. For this reason the MWAL (Multi-Standard Wireless Adaptation Layer) provides an Application Programmers' Interface. The communication between the application and the MWAL daemon is made by using a couple of local socket (one for the commands generated by the application and one for the events detected by the MWAL daemon).
The mentioned document WO 02/43348 A1 provides the seamless handover by using an adapted Session Layer with a security sub-layer (Session Mobility). This adapted Session Layer has to intercept and to manage all the TCP/UDP traffic produced by the client and server applications in order to grant the seamless handover (see FIG. 35). Furthermore, in order to work properly, it has to be implemented in a platform specific way and this hinder and reduce the platform portability. Finally, the adapted Session Layers, interacting via a common session protocol, must be available on the same devices that are running the client or the server application and not on different devices. This Session Mobility gives the possibility to handle the security at Session Layer, making possible to provide VPN solutions to enforce strong end-to-end security on an application-to-application level but its major drawback is that it lacks in architectural flexibility, requiring the adapted Session Layer to be installed in any devices involved in the communication.
Finally the mentioned document “Supporting CORBA Applications in a Mobile Environment” MOBICOM '99 by HAAHR M et al. is only one of the numerous solutions providing the seamless handover by offering to the client and server application developers a software framework with a set of API to be used. The major drawback of this kind of solutions is the backward compatibility. The seamless handover can be granted only if the client and server applications have been developed using the provided software framework. All the already developed and largely used client and server applications can't enjoy the seamless mobility.